Optimize QueryIndex key comparison in matching hot path#1243
Merged
brharrington merged 2 commits intoJun 4, 2026
Conversation
forEachMatch compared every id key against a node's key via compare(), which did up to two "name".equals() checks plus a compareTo on each call. Since a node's key is fixed, hoist the "name" check out of the per-tag loop, and skip the name-first special-casing entirely for tag positions >= 1 (only position 0 holds the synthesized name key, and the tag list is sorted so the special-casing is unnecessary there). Adds a QueryIndexMatch JMH benchmark exercising the LWC bridge matching path (5k subscription queries x 200 ids). Measured on JDK 25: current 144.46 us/op hoist 137.88 us/op +peel 132.67 us/op (~8% faster, no allocation change)
Inlining the position-based comparison as a nested ternary in forEachMatch pushed its NPath complexity to 331 (threshold 200). Extract the comparison into a compareTagKey helper, moving the branching out of forEachMatch. No behavior change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
forEachMatch compared every id key against a node's key via compare(), which did up to two "name".equals() checks plus a compareTo on each call. Since a node's key is fixed, hoist the "name" check out of the per-tag loop, and skip the name-first special-casing entirely for tag positions >= 1 (only position 0 holds the synthesized name key, and the tag list is sorted so the special-casing is unnecessary there).
Adds a QueryIndexMatch JMH benchmark exercising the LWC bridge matching path (5k subscription queries x 200 ids). Measured on JDK 25:
current 144.46 us/op
hoist 137.88 us/op
+peel 132.67 us/op (~8% faster, no allocation change)